The introduction and increasingly wide usage of computers in the past 30 years has made heretofore unavailable information increasingly accessible. This information or data explosion has increased exponentially in the past decade with the advent of personal computers and the large linking of computers via local and wide area networks. These computers or workstations coupled with each other can transmit many types of information from one geographical location to another geographical location. This information can be in form of voice, video, and data, which have been commonly termed as “multi-media.” Information transmitted over the internet or internet “traffic” has increased dramatically in recent years. In fact, the increased traffic has caused congestion, which leads to problems in responsiveness and throughput. This congestion is similar to the congestion of automobiles on a freeway. As a result, individual users, businesses and others have been spending more time waiting for information, and less time on productive activities. Additionally, information being sent from one site to another through electronic mail, may not reach its destination in a timely or adequate matter. In effect, Quality of Service (“QoS”) of the internet has decreased to the point where some messages are being read at some time significantly beyond the time the messages were sent.
The quality of service is often measured by responsiveness, including the amount of time spent waiting for images, texts, and other data to be transferred, and by throughput of data across the internet, and the like. Three main sources of data latency include: 1) the lack of bandwidth at the user (or receiving) end; 2) the general congestion of internet; and 3) the lack of bandwidth at the source (or sending).
The wide-spread growth of the internet can be attributed to the use of standard network protocols in routers, which couple different networks together. A typical network protocol, such as TCP/IP, includes an application layer, a host-to-host protocol layer (TCP/UDP), an internet protocol layer (IP) which is a network protocol and a physical layer. Often, routers are used to forward packets from different networks at the physical layer and the network layer.
Referring to FIG. 1, depicted therein is a network-wide view of the typical system for communicating across the internet (10), between a local source node (12), and a target system (14) in the form of data packets sent over the internet. It has long been known that fragmentation of such data packets by routers (24, 26, 28, and 30) is generally undesirable. The reason is that such fragmentation and reassembly is an expensive and time-consuming process which causes applications to wait until all fragments are received and reassembled. Thus, it is desirable to determine a larger size packet which may be transmitted without being fragmented.
Maximum transmission unit (MTU) of a network interface is defined as the maximum size of a packet that can be sent out over the network interfaces (32, 34, and 36). In addition, the internet (10) is comprised of many networks with different MTUs. Internet traffic usually undergoes fragmentation at the source node and reassembly at the receiving node if the size of the data packet is larger than the MTU of the outgoing interface, or the interface of an intermediate router (24, 26, 28, 30). However, such fragmentation reassembly is a time-consuming and expensive process and causes applications to wait until all fragments are received and reassembled. It is possible to specify that Internet Protocol (IP) data not be fragmented however, this causes IP packets, which are larger than the MTUs, to be dropped.
Path MTU (PMTU) of an internet path is defined as the minimum of the MTUs of all the segments of the path it is comprised of. Restated, PMTU is the maximum size of data packet that can be passed through all the lengths without fragmentation between a given source and a destination. Data fragmentation and reassembly can be avoided if the PMTU of the internet path between the source and the destination was known. The IETF (Internet Engineering Task Force), which has assumed responsibility for the continued development of the internet, has published a “request for comment” or RFC 1191, which describes a technique for discovering PMTUs of internet paths by utilizing the “don't fragment” (DF) bit in the IP header to discover the PMTU. RFC 1191 describes the technique for discovering PMTUs of internet paths for IP version 4 (IPv4). Setting this DF option in the outgoing data (payload) IP packet enables the sending node to receive an error when the IP packet cannot be sent out because it is larger than the MTU of the outgoing interface and, as a result, the data packet is dropped. The source host (12) initially assumes the PMTU of the path is the known MTU of the first hop (32), and sends all packets with the DF bit set. If any of the routers (24, 26, 28, and 30) cannot forward the data packets without fragmentation, the particular router will discard them and return a “Destination Unreachable DF Set and Fragmentation Required” (Needfrag Error) ICMP message and the source host reduces its assumed PMTU. The PMTU discovery process ends when data packets are delivered without error, or the host may elect to end discovery process by ceasing to set the DF bit.
RFC 1981 describes the technique for discovering PMTUs of internet paths for IP version 6 (IPv6). For path MTU discovery for IPv6, the source node initially assumes that the PMTU is the known MTU of the first hop in the path. If a packet sent on that path is too large to be forwarded by some node along the path, that node will discard the packet and return an ICMP IPv6 “Packet Too Big” error message. Upon receipt of such message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the “Packet Too Big” error message. The path MTU discovery process ends when the node's estimate of the PMTU is less than or equal to the actual PMTU. Several iterations of the packet-sent/Packet-Too-Big-message-receive cycles may occur before the path MTU discovery process ends, as there may be links with smaller MTUs further along the path.
The PMTU may change over time, due to changes in routing topology. Reductions of the PMTU are detected by “Packet Too Big” error messages. To detect increases in the path PMTU, a node periodically increases its learned path MTU (LPMTU). This will almost always result in packets being discarded and “Packet Too Big” error messages being generated, because in most cases, the PMTU of the path will not have changed. Therefore, attempts to detect increases in the path's PMTU should be done infrequently. The probing is costly, because probing is done on a per destination basis and probes of size greater than the LPMTU are used. RFC 1981 defines a mechanism that probes are sent once every five or ten minutes so as to reduce the cost. A source node, which is a proxy server or web server, can be originating connections to as many as 4,000 other nodes on the internet. In order to detect increases in PMTU information for all 4,000 nodes, the source will have to send out 4,000 probe packets to each of the destinations every five or ten minutes. This leads to unnecessary wastage of bandwidth and processor cycles. In the worst case, this could result in a flood of error messages from intermediate routers.
If PMTU increments are not tracked by sending probes, the LPMTU will keep on decreasing until it reaches the protocol defined the minimal link MTU (576 for IPv4, 1280 for IPv6). This results in sub-optimal utilization of the path. As an example, if the LPMTU is one-half of the PMTU, then for sending out data of size three-quarters of PMTU, two packets are needed, whereas, in reality, one would be sufficient. Alternatively, periodically setting the LPMTU to the possible maximum, which is the directly connected link MTU, will create bursts of error messages, if the currently set LPMTU is higher than the actual PMTU.
While packet drops and data loss were not major issues for early traditional internet applications, such as mail, FTP, telnet, etc., they can cause serious quality of service (QoS) problems for applications involving multi-media data, such as audio and video teleconferencing, video serving, etc. Data packet drops must be kept to a minimum for such applications, as they involve real-time, data encoding and, hence, retransmission of a lost or dropped packet may simply not be an option. Therefore, specifying not to fragment IP data may not be useful for multi-media data if there is a need to avoid fragmentation and reassembly for performance reasons. As such, existing PMTU discovery processes are ill-suited to dynamically detect the increments in PMTU due to the aforementioned route changes.